HAPI Documentation

An instant in consensus time

The list of account balances for all accounts, after handling all transactions with consensus timestamp up to and including the above instant

Includes all currency balances (both hbar and token) of a single account in the ledger.

The account

The ID for an a cryptocurrency account

The account's hbar balance

The list of the account's token balances

A unique token id

Unique identifier for a token

A number of transferable units of the identified token

Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).

The Account for which information is requested

The ID for an a cryptocurrency account

Specifies the start (including) of the range of NFTs to query for. Value must be in the range (0; ownedNFTs]

Specifies the end (including) of the range of NFTs to query for. Value must be in the range [start; ownedNFTs]

Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither

The Account that this record is for

The ID for an a cryptocurrency account

List of NFTs associated to the account

The ID of the token

Unique identifier for a token

The serial number of the NFT

The effective consensus timestamp at which the NFT was minted

Represents the unique metadata for a given NFT instance

The Account ID that sends/receives cryptocurrency or tokens

The ID for an a cryptocurrency account

The amount of tinybars (for Crypto transfers) or in the lowest denomination (for Token transfers) that the account sends(negative) or receives(positive)

The shard number (nonnegative)

The realm number (nonnegative)

A nonnegative account number unique within its realm

The shard number (nonnegative)

The realm number (nonnegative)

A nonnegative number unique within its realm

Contains current Fee Schedule

Contains next Fee Schedule

A minimum, the calculated fee must be greater than this value

A maximum, the calculated fee must be less than this value

A constant contribution to the fee

The price of bandwidth consumed by a transaction, measured in bytes

The price per signature verification for a transaction

The price of RAM consumed by a transaction, measured in byte-hours

The price of storage consumed by a transaction, measured in byte-hours

The price of computation for a smart contract transaction, measured in gas

The price per hbar transferred for a transfer

The price of bandwidth for data retrieved from memory for a response, measured in bytes

The price of bandwidth for data retrieved from disk for a response, measured in bytes

Fee paid to the submitting node

Fee paid to the network for processing a transaction into consensus

Fee paid to the network for providing the service associated with the transaction; for instance, storing a file

List of price coefficients for network resources

The fees for a specific transaction or query based on the fee data.

FeeSchedule expiry time

An exact date and time, with a resolution of one second (no nanoseconds).

The shard number (nonnegative)

The realm number (nonnegative)

A nonnegative File number unique within its realm

list of keys

A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
A Key can be a smart contract ID, which means that smart contract is to authorize operations as if it had signed with a key that it owned. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key.
A key can be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements.
A Key can be a list of keys. Their use is dependent on context. For example, a Hedera file is created with a list of keys, where all of them must sign a transaction to create or modify the file, but only one of them is needed to sign a transaction to delete the file. So it's a single list that sometimes acts as a 1-of-M threshold key, and sometimes acts as an M-of-M threshold key.
A Key can contain a ThresholdKey or KeyList, which in turn contain a Key, so this mutual recursion would allow nesting arbitrarily deep. A ThresholdKey which contains a list of primitive keys (e.g., ed25519) has 3 levels: ThresholdKey -> KeyList -> Key. A KeyList which contains several primitive keys (e.g., ed25519) has 2 levels: KeyList -> Key. A Key with 2 levels of nested ThresholdKeys has 7 levels: Key -> ThresholdKey -> KeyList -> Key -> ThresholdKey -> KeyList -> Key.
Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys. Only ed25519 primitive keys are currently supported.

Sending account

The ID for an a cryptocurrency account

Receiving account

The ID for an a cryptocurrency account

Serial number that is being transferred

The IP address of the Node with separator & octets encoded in UTF-8. Usage is deprecated, ServiceEndpoint is preferred to retrieve a node's list of IP addresses and ports

The port number of the grpc server for the node. Usage is deprecated, ServiceEndpoint is preferred to retrieve a node's list of IP addresses and ports

Usage is deprecated, nodeAccountId is preferred to retrieve a node's account ID

The node's hex-encoded X509 RSA public key

# A non-sequential identifier for the node

# The account to be paid for queries and transactions sent to this node

The ID for an a cryptocurrency account

# The hex-encoded SHA-384 hash of the X509 cert used to encrypt gRPC traffic to the node

# A node's service IP addresses and ports

A description of the node, with UTF-8 encoding up to 100 bytes

The amount of tinybars staked to the node

Metadata of all nodes in the network

The shard number (nonnegative)

The realm number (nonnegative)

A nonnegative shard number

A nonnegative realm number

A nonnegative schedule number

Increases with incompatible API changes

Increases with backwards-compatible new functionality

Increases with backwards-compatible bug fixes

The 32-bit IPv4 address of the node encoded in left to right order (e.g. 127.0.0.1 has 127 as its first byte)

The port of the node

list of name value pairs of the application properties

name of the property

value of the property

any data associated with property

the shard number (nonnegative)

each signature corresponds to a Key in the KeyList

A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
The definition of Key uses mutual recursion, so it allows nesting that is arbitrarily deep. But the current API only accepts Key messages up to 3 levels deep, such as a list of threshold keys, each of which is a list of primitive keys. Therefore, the matching Signature will have the same limitation. This restriction may be relaxed in future versions of the API, to allow deeper nesting.
This message is deprecated and succeeded by SignaturePair and SignatureMap messages.

Each signature pair corresponds to a unique Key required to sign the transaction.

First few bytes of the public key

A valid signature set must have at least this many signatures

List of all the keys that can sign

A list of keys

for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null

A unique token id

Unique identifier for a token

A number of transferable units of the identified token

Tokens divide into 10^decimals pieces

A number of transferable units of a certain token.

A nonnegative shard number

A nonnegative realm number

A nonnegative token number

The ID of the token

Unique identifier for a token

The Symbol of the token

For token of type FUNGIBLE - the balance that the Account holds in the smallest denomination. For token of type NON_FUNGIBLE - the number of NFTs held by the account

The KYC status of the account (KycNotApplicable, Granted or Revoked). If the token does not have KYC key, KycNotApplicable is returned

Possible KYC statuses returned on TokenGetInfoQuery or CryptoGetInfoResponse in TokenRelationship

The Freeze status of the account (FreezeNotApplicable, Frozen or Unfrozen). If the token does not have Freeze key, FreezeNotApplicable is returned

Possible Freeze statuses returned on TokenGetInfoQuery or CryptoGetInfoResponse in TokenRelationship

The number of decimal places a token is divisible by. Always 0 for tokens of type NON_FUNGIBLE

The ID of the token

Unique identifier for a token

Applicable to tokens of type FUNGIBLE. Multiple list of AccountAmounts, each of which has an account and amount

An account, and the amount that it sends or receives during a cryptocurrency or token transfer.

Applicable to tokens of type NON_FUNGIBLE

The shard number (nonnegative)

The realm number (nonnegative)

Unique topic identifier within a realm (nonnegative).

A particular transaction or query

Resource price coefficients

The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid

The Account ID that paid for this transaction

The ID for an a cryptocurrency account

Whether the Transaction is of type Scheduled or no

Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)

An account, and the amount that it sends or receives during a cryptocurrency or token transfer.

Short publicly visible memo about the topic. No guarantee of uniqueness.

Access control for updateTopic/deleteTopic.
Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.
If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic
is disallowed.

A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
A Key can be a smart contract ID, which means that smart contract is to authorize operations as if it had signed with a key that it owned. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key.
A key can be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements.
A Key can be a list of keys. Their use is dependent on context. For example, a Hedera file is created with a list of keys, where all of them must sign a transaction to create or modify the file, but only one of them is needed to sign a transaction to delete the file. So it's a single list that sometimes acts as a 1-of-M threshold key, and sometimes acts as an M-of-M threshold key.
A Key can contain a ThresholdKey or KeyList, which in turn contain a Key, so this mutual recursion would allow nesting arbitrarily deep. A ThresholdKey which contains a list of primitive keys (e.g., ed25519) has 3 levels: ThresholdKey -> KeyList -> Key. A KeyList which contains several primitive keys (e.g., ed25519) has 2 levels: KeyList -> Key. A Key with 2 levels of nested ThresholdKeys has 7 levels: Key -> ThresholdKey -> KeyList -> Key -> ThresholdKey -> KeyList -> Key.
Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys. Only ed25519 primitive keys are currently supported.

Access control for submitMessage.
If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).

A Key can be a public key from one of the three supported systems (ed25519, RSA-3072, ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
A Key can be a smart contract ID, which means that smart contract is to authorize operations as if it had signed with a key that it owned. The smart contract doesn't actually have a key, and doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key.
A key can be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements.
A Key can be a list of keys. Their use is dependent on context. For example, a Hedera file is created with a list of keys, where all of them must sign a transaction to create or modify the file, but only one of them is needed to sign a transaction to delete the file. So it's a single list that sometimes acts as a 1-of-M threshold key, and sometimes acts as an M-of-M threshold key.
A Key can contain a ThresholdKey or KeyList, which in turn contain a Key, so this mutual recursion would allow nesting arbitrarily deep. A ThresholdKey which contains a list of primitive keys (e.g., ed25519) has 3 levels: ThresholdKey -> KeyList -> Key. A KeyList which contains several primitive keys (e.g., ed25519) has 2 levels: KeyList -> Key. A Key with 2 levels of nested ThresholdKeys has 7 levels: Key -> ThresholdKey -> KeyList -> Key -> ThresholdKey -> KeyList -> Key.
Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys. Only ed25519 primitive keys are currently supported.

The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by
automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality
is supported by HAPI).
Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.
Required.

Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew
functionality is supported by HAPI).
The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic
can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension
is possible with the account's funds).
If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.

The ID for an a cryptocurrency account

Topic identifier.

Unique identifier for a topic (used by the consensus service)

Standard info sent from client to node, including the signed payment, and what kind of response is requested
(cost, state proof, both, or neither).

The Topic for which information is being requested

Unique identifier for a topic (used by the consensus service)